home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
ietf
/
ident
/
ident-minutes-92jul.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
5KB
|
156 lines
Editor's Note: Minutes received 7/20
CURRENT_MEETING_REPORT_
Reported by Mike St. Johns/DOD and Dave Borman/Cray Research
Minutes of the TCP Client Identity Protocol Working Group (IDENT)
Discussion Items
o Security Section
o Format of User IDs
o Character Set
o Error Response
o MIB
Security Section
The security section has been argued/discussed to death on the mailing
list - the current text represents what the Chair considers a reasonable
compromise. The Chair did not want to reopen the section again.
After a little discussion about generalities (e.g., Is the section too
big?; Is the section too small?), Marshall Rose stated that ``Finger has
a large security section, it's a fact of life that with documents like
this a longer security section is needed.'' Steve Crocker said that ``I
read this from scratch - thought about dropping last two paragraphs, but
then decided they were important.'' The Chair polled the room on three
questions:
1. Section too strict: 0
2. Section not strict enough: 2
3. OK as is: 13
4. No opinion: 5
(Note that there was some overlap between ``not strict enough'' and
``OK'' - the ``too strict'' people were willing to accept as stands).
The Chair said there was not enough heartburn to warrant reopening
section and was not shouted down, so section is CLOSED and will stand as
it is currently.
At the request of Marshall Rose, the Group discussed the MIB document
out of turn.
There was a brief discussion on how MIB document relates to Ident
protocol. We noted that the only critical overlap was the security
section. As we had closed the security section, without objection, the
Chair declined to pull the MIB document back from standards submission.
Please note that objectors may send their comments to the IESG during
the normal two week comment period once the document is announced.
1
Format of Userids
There was a lot of very good discussion here on character length and
format: Why limit UNIX to 8 characters? Should we get rid of OPSYS
field? The character set information is useful and the rest should be
arbitrary? MIME is specifying US-ASCII instead of NVT-ASCII.
The final result of the discussion was to redesignate OCTET as a
character set indicator; to remove the syntax implications from the
OPSYS ID [a ``real'' operating system identifier implies a ``real'' user
identifier, but does not indicate any specific syntax of the user
identifier]; and to make US-ASCII the default character set vs
NVT-ASCII.
Random Interjections
There was a brief discussion on the feasibility of using UDP for
transport but the general consensus was that it was not a good idea. By
using UDP as the transport, it would be very easy to spoof the response
- even more so than is possible in TCP.
The point was make that there needs to be something in overview about
the client shutting down the connection if it gets no response. The
Chair accepted this and took for action.
Stever Crocker asked if the server is allowed to respond on a selected
basis, and is the server allowed to respond with something not directly
interpretable? The Chair deferred the first part for later discussion,
but pointed Steve at the ``OCTET'' operating system identifier and the
``OTHER'' character set identifier for the second part.
Steve also indicated a problem with the ``Query/Response'' section; he
got lost reading this. He suggested ``Port on Client Machine/Port on
Server Machine'' vs. ``local/remote''. The Chair accepted this and
will edit it.
Character Sets
This section remains open for one go-around on the items suggested
above.
Error Responses
There were two proposals:
1. Allowing the server to return ``NONE'' for machines like MS/DOS or
others which don't have the concept of a userid. This was rejected
on the basis we'd have to reserve ``NONE'' and no one could use it
as a userid. Systems like this should use the ``NO-USER'' error
code instead.
2
2. Allowing the server to return ``HIDDEN-USER'' as an error code.
The code would mean the system had valid user information for this
query, but refused to return it at the request of the user. The
consensus was to accept it.
Attendees
Steve Alexander stevea@i88.isc.com
Mark Baushke mdb@cisco.com
David Borman dab@cray.com
Luc Boulianne lucb@cs.mcgill.ca
Stephen Crocker crocker@tis.com
Peter DiCamillo Peter_DiCamillo@brown.edu
Chas DiFatta chas@sei.cmu.edu
Tom Farinelli tcf@tyco.ncsc.mil
Barbara Fraser byf@cert.org
Ned Freed ned@innosoft.com
Cliff Frost cliff@cmsa.berkeley.edu
Pria Graves priag@nsd.3com.com
Bradley Rhoades bdrhoades@mmc.mmmg.com
April Richstein abm@tycho.ncsc.mil
Marshall Rose mrose@dbc.mtview.ca.us
Robert Shirey shirey@mitre.org
Jeremy Siegel jzs@nsd.3com.com
Michael St. Johns stjohns@umd5.umd.edu
Theodore Ts'o tytso@mit.edu
John Wagner jwagner@princeton.edu
Walter Wimer walter.wimer@andrew.cmu.edu
3